perm filename HSTHST.PRO[DLN,MRC]3 blob
sn#318455 filedate 1977-11-23 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00018 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00003 00002 DIALnet memo #2
C00005 00003 CONVENTIONS USED IN THIS DOCUMENT
C00007 00004 PREFACE
C00011 00005 INTRODUCTION
C00016 00006 GOALS
C00019 00007 THE DIALNET CONTROL PROGRAM
C00023 00008 DATA FLOW AND ERROR DETECTION
C00029 00009 DATA FLOW AND ERROR DETECTION (continued)
C00032 00010 CHECKSUM ALGORITHM
C00035 00011 PACKET FORMAT
C00038 00012 OP CODES
C00042 00013 OP CODES (continued)
C00046 00014 EXAMPLES OF DIALNET INTERACTIONS
C00048 00015 GLOSSARY
C00053 00016 GLOSSARY (continued)
C00056 00017 REFERENCES
C00059 00018 ACKNOWLEDGEMENTS
C00060 ENDMK
C⊗;
DIALnet memo #2
SAILON silver girl
DIALnet Protocols
(or, the Protocols of DIAL)
Host-Host Protocols
Mark Crispin
11/23/77
These protocols are being developed as part of the DIALnet project at the
Stanford University Artificial Intelligence Laboratory supported by NSF grant
MCS 77-02080 with John McCarthy as Principal Investigator. The project is
described in a paper available online at ARPAnet host SU-AI as
DIALNE.MEM[DLN,MRC] (DIALnet Memo #1).
This is HSTHST.PRO[DLN,MRC] at ARPAnet host SU-AI (octal 13, decimal 11.).
CONVENTIONS USED IN THIS DOCUMENT
All numbers without an explicit base (ie, octal or decimal) specified
should be interpreted as octal unless the number is immediately followed by a
dot, in which case it is decimal. However, numbers with intervening spaces
every three digits should be treated as binary (the intervening spaces are used
to facilitate conversion to octal).
All three-digit octal numbers should be interpreted as representing an
8.-bit byte, with bits right-justified within the number (ie, from 000 to 377).
Bytes are expressed in the form as returned by the modem (ie, lsb first); ie,
105 is transmitted in the bit stream as 101 000 10.
All six-digit octal numbers should be interpreted as representing a 16.-bit
double-byte, with bits right-justified within the number (ie, from 000000 to
177777). Double-bytes are expressed in the form returned by the modem (ie, low
order byte and lsb first); ie, 010041 is transmitted as 100 001 000 000 100 0.
PREFACE
"Aren't you glad you use DIALnet? Don't you wish everybody did?"
This document specifies a protocol for use in communication between Host
computers using the DIALnet protocols. In particular, it provides for
connection of independent processes in different hosts, control of the flow of
data of established connections, and other related functions.
Although self-contained, this document specifies only one of the DIALnet
protocols. In particular, while this protocol specifies how data is to be
transmitted in between processes on DIALnet, it does not define in what format
the data is to be sent, nor does it define how the processes are expected to use
the data received. It merely attempts to provide an error-free link between
processes.
This Host-Host protocol is the "second level", or secondary protocol used
on DIALnet. The primary protocol is the protocol of the dialing modems. The
Process-Process protocols, or tertiary protocols, are described elsewhere.
Questions concerning DIALnet protocols should be addressed to:
Mark Crispin
Stanford Artificial Intelligence Laboratory
1600 Arastradero Road
Stanford, California 94305
(415) 491-1407
MRC@SU-AI
Copies of all DIALnet-related correspondence should be sent to John
McCarthy (DIALnet principal investigator) and Les Earnest at the above US mail
address or via ARPAnet mail to JMC@SU-AI and LES@SU-AI.
It is the intent of the author that these protocols are both simple in
their implementation and powerful in their operation. Certainly a major design
consideration was to design protocols that ordinary mortals could implement on
their systems.
The intended audience of DIALnet ranges from fairly small to quite large
systems, however, DIALnet has been designed to be nice for medium sized
time-sharing systems, such as PDP-10's and DECsystem-20's.
INTRODUCTION
DIALnet provides a capability for geographically separated computers,
called hosts, to communicate with each other. The host computers typically
differ from one another in type, speed, word length, operating system, etc.
Each computer utilizes DIALnet via the ordinary phone lines and special modems
using the primary protocol.
This protocol, however, is insufficient to specify meaningful communication
between processes running in two dissimilar hosts. The processes must have some
agreement as to the method of initiating communication, the interpretation of
transmitted data, etc. While it is possible for individual pairs of hosts or
processes interested in communication with each other to establish private
protocols, it is more desirable for a DIALnet-wide set of standard protocols to
be established to minimize the amount of implementation effort involved in
DIALnet-wide communication.
Hence, a "layered" approach to communications protocols similar to those of
the ARPAnet are specified here. The primary layer is the protocol of the
dial-up modems. The secondary protocol, described here, is the host-host
protocol, which is used by all higher-level protocols. The tertiary protocols,
described elsewhere, include: (in approximate order of importance)
MAIL Sending and receiving letters between different users at different
hosts. These "letters" tend to be things like memos or such which are
read by the user at his/her convenience instead of immediately.
SEND Person-to-person immediate line at a time communication.
LINK Person-to-person immediate character at a time communication.
INFO A general service providing information at the host, including access
information, currently logged-in users, how not-logged-in users may be
contacted, etc.
FTP File transfer protocol for reading, writing, and manipulating files at a
remote host.
TELNET Mapping of an arbitrary console keyboard/printer at the local host to a
DIALnet virtual terminal which communicates with a terminal server
process at the remote host. The remote host's server process maps the
virtual terminal's protocol into the host's own local terminal's
protocol. In this manner, users of one host can connect to another and
log in, etc. as if they were at a local console at the remote host.
There are probably going to be several levels of TELNET; the first and
simplest will be a simple "connection" like a phone connection with no
options. Others, such as ARPAnet-compatible TELNET (ARPATLNT), display
SUPDUP (SUPDUP), and other forms of remote terminal access will be
provided.
GOALS
1. An essentially error-free data link. By this I mean no undetected errors,
no missed data, and error correction which is invisible to the user
process.
2. Simple enough to put into small systems yet powerful enough to handle
sophisticated data communications.
3. Non-hairy implementation.
4. Optimal for mailing and other message communication purposes, then for file
transfer, then for telnetting. DIALnet is intended primarily for
communications between two hosts where the physical amount of data
transmitted and the actual connect time is relatively short.
5. Efficient data communication with no deadlock situations.
6. Allow for upwards-compatible extensions (such as multiplexed connections) in
future incantations of DIALnet.
7. Allow for private protocols to be established.
NON-GOALS
1. Multiplexed connections. This is impractical with present technology; it
will be reconsidered in the future.
2. Direct interface with other networks. The MAIL protocol will consider this
problem though.
3. The comprehensive features of the ARPAnet or other high-bandwidth networks.
DIALnet will provide the same USER services as a network such as the
ARPAnet; but it is important to realize that DIALNET is a low-bandwidth
communication protocol and not a physical network such as the ARPAnet.
4. Low-level handling of byte sizes of other than 8.-bit bytes.
5. Variable-format packets. It makes everything simpler to use fixed format.
6. Encryption at the host-host level.
7. Use of non-ASCII character sets at the host-host level.
THE DIALNET CONTROL PROGRAM
The DIALnet control program is the program (or set of programs--it can be
many processes) within each host which is responsible for establishing and
breaking connections as well as controlling the data flow over the connections.
Normally, the DCP will be part of the operating system or the front end
processor, although it could be an I/O subroutine in a user program. However,
it is suggested that on any sort of timesharing or multiprocessing system that
there be a separate process which interfaces between the user process and the
"network"; this makes the programming task easier for the user (since the user
is given a data link with the DIALnet host-host protocol headers already parsed
out and all error handling already performed) and allows for a consistent
interface with other hosts.
For the DCP to perform its work, it must communicate with the DCPs running
on other hosts. To allow this, a rigidly formatted packet structure has been
established for messages exchanged between the individual DCP's. The format of
this packet is discussed later on.
Another concern which the DCP should handle is the problem of buffering and
allocation. The DCP can set a maximum number of bytes of tertiary data (ie, the
data part of an MSG packet) which may be sent before the connection becomes
"frozen", waiting for a further allocation.
The purpose of allocation is to allow hosts with limited buffering
capability to use the DIALnet facilities without having data overruns and the
resulting loss of efficiency in retransmitted packets. Note that allocation
does not affect retransmission, packet headers or trailers, or the data area of
any packets other than MSG packets. A host must be prepared to accept and
process non-MSG packets at any time.
This only covers tertiary data. The DCP normally should run at a high
enough priority to be able to handle all non-MSG packets coming in. If it
cannot, it still can win (sort of) by failing to acknowledge a packet which it
lost; eventually it will have to be retransmitted. It should be noted that this
is rather inefficient and it is best for the DCP to be a low-level process that
is guaranteed to be able to process non-MSG packets without buffering.
DATA FLOW AND ERROR DETECTION
All data is sent in the form of packets, which contain a packet header,
some data, and a packet trailer. The packet header serves to identify the type
of packet (ie, its functionality) and the size of the data area. The packet
trailer provides a checksum for the packet.
Packets have the same general format, illustrated on the PACKET FORMAT
page. They begin with a fixed start of packet code, followed by an op code,
followed by the rest of the packet contents, and terminated by a checksum and an
end of packet code. The reason for this rather inflexible scheme was to make
implementation as simple as possible and to provide a clear, unambigious format
for packets. Using this scheme it is possible for the same read-packet routine
to read all types of input packets.
Both the packet header and the packet trailer begin with a fixed value.
This is used in packet synchronization. The Start-Of-Packet (SOP) code is 227
and the End-Of-Packet (EOP) code is 226. These values were selected for two
reasons: (1) they are unlikely to occur frequently in ASCII data, and (2) they
are unlikely to be generated by line noise. If a byte which has the value of an
SOP or an EOP occurs within a packet, it must be quoted by a preceeding SOP.
All packets, except for acknowledgement (ACK) packets, must be acknowledged
with ACK. It is acceptable to send extra acknowledgements at any time; as an
acknowledgement also serves as a request for more packets. All packets except
for acknowledgement packets increment the packet number, which wraps around to
001 on overflow.
Packets must be received in sequence, with the exception of ACK and RST
packets. These op codes always take a packet number of 000, since they do not
use the normal data flow mechanism (RST initializes it). However, RST's must
still be acknowledged (ie, ACK 000 verifies a reset).
In the discussion below, timeout values are given. These times are the
maximum amount of time delay between the start of a wait for an event and the
time when the timeout action should be taken. It is possible not to use
timeouts by continuously transmitting, but it is rather inefficient.
For efficiency, the sender may send up to 3. packets before getting an ACK
for the first of the three (in other words, up to three packets may be awaiting
acknowledgement at any one time). This window size may be changed by using the
winning WIN opcode to any value between 1 and 126; the latter limit is to
prevent lossage which might (however unlikely) occur with wraparound if all the
packets before it are lost.
In addition, there is a timeout of 10. seconds, and if an acknowledgement
is not received for any packet within that time, transmission starts over with
that packet.
The receiver must reply to every packet it receives with an ACK if the
packet was received successfully or an ERR if it was not. If transmission stops
within a packet and is not resumed within 15. seconds, the receiver flushes what
it has received of the packet so far and sends an ERR. In addition, if the
receiver has not received a new packet within 5. seconds after the end of the
previous packet, it should repeat the ACK.
If the receiver receives a packet it has already acknowledged, it should
ignore it and repeat the ACK. If an out-of-sequence packet is received, it
should send an ERR and discard that packet.
DATA FLOW AND ERROR DETECTION (continued)
If the sender intends to "go idle" (ie, wishes to stop transmitting real
data for a while), it should send a NOP, which should be repeated every 5.
seconds. This assures the receiver that the sender is still up.
If no packets (good or otherwise) have been received from the sender in 30.
seconds, the receiver should assume that the sender is dead, send an ERR, and
hang up. If no good packets have been received within 120. seconds, the
receiver should assume that the connection is faulty, send an ERR, and hang up.
The receiver is not obliged to wait for ACKs in this case.
It should be noted that if the other host is transmitting a packet, the
start of the waiting for next packet or waiting for ACK time-out time commences
from the end of its packet.
In the event of a transmission error, the receiver should send an ERR and
scan for an SOP that is not associated with another SOP or EOP. This wins
because EOP and SOP are specifically excluded from being op-codes. There is
still the problem of the noise condition ending between a pair of SOP's in a
quoting situation, however, in this case the packet as read is fairly certain to
violate protocol and be flushed, at the worse when an unexpected or missed EOP
occurs.
When an ERR is received the host should immediately stop sending its
current packet and start re-transmitting with the first unacknowledged packet
still pending. To prevent confusion, it should send an EOP after the incomplete
packet to prevent quoting problems.
CHECKSUM ALGORITHM
The packet checksum algorithm used is a cyclic redundancy check. Reading
the packet as a bit stream first the running sum is left shifted by 1, and if an
overflow occurs (ie, the 200000 bit is set) the input bit is complemented; and
if the resulting value is 1, the running sum is XOR'd with 2↑12.+2↑5.+1
(010041). The running sum initializes at 000000 for each packet.
The checksum includes all of the packet header variables and the entire
data area. It does NOT include the packet trailer or the SOP/EOP synch codes.
In PDP-10 assembly code, this is:
; CHKBIT adds a bit to the checksum in SUM.
;
; Call: MOVE BIT,<bit from data stream>
; PUSHJ P,CHKBIT
; <return>
CHKBIT: LSH SUM,1 ; SUM shifts left
TRZE SUM,1←16. ; Overflow set?
XORI BIT,1 ; XOR overflow with incoming bit
TRNE BIT,1 ; If the result is 1,
XORI SUM,1←12.+1←5+1 ; bring it in
POPJ P, ; Return to caller
For the PDP-11:
; CHKBIT adds a bit to the checksum in SUM.
;
; Call: MOV <bit from data stream>,BT
; JSR PC,CHKBIT
; <return>
CHKBIT: ASL SUM ; SUM shifts left
ADC BT ; XOR BT with high order bit of SUM
ROR BT ; If the result is 0,
BCC CHKRTN ; return to caller
MOV #010041,R0 ; Else get the polynomial
XOR R0,SUM ; and bring it in
CHKRTN: RTS PC ; Return to caller
PACKET FORMAT
_________________________________________
| |
| SOP marker |
| |
|=======================================|
| PACKET HEADER |
|=======================================|
| |
byte 1 | Reserved * |
| |
|---------------------------------------|
| |
byte 2 | Op code |
| |
|---------------------------------------|
| |
byte 3 | Packet number |
| |
|---------------------------------------|
| |
byte 4 | Data size (bytes) |
| |
|=======================================|
| PACKET DATA (optional) |
|=======================================|
| |
| |
| |
| |
byte 0 → | Data (<size> bytes) |
<size-1> | |
| |
| |
| |
|=======================================|
| PACKET TRAILER |
|=======================================|
| |
byte 1 | Packet checksum (low) |
| |
|- - - - - - - - - - - - - - - - - - - -|
| |
byte 2 | Packet checksum (high) |
| |
|=======================================|
| |
| EOP marker |
| |
|_______________________________________|
(*) Byte 1 of the packet header is reserved for future use and MUST be zero.
DCP's should ignore this byte on input.
From this diagram, it can be seen that the minimum packet size is 8. bytes
and the maximum is 263. bytes. At 1200. baud, transmission timings range from
.067 second to 2.2 seconds.
OP CODES
In the descriptions below, certain arguments are passed along with the
commands. These arguments are listed in the order in which they occur, along
with their byte size. They all occur in the DATA field of the packet.
The op codes corresponding to the values of SOP and EOP are specifically
illegal and are never used.
CODE 000 NOP NO-OP DCP ↔ DCP message
This command is a no-operation and should be ignored by the receiver except
that the packet still has to be acknowledged. It is used as an "idling" packet
to indicate that the sender is still alive but not transmitting anything.
CODE 001 RPC REQUEST PROCESS CONNECTION process → DCP message
8. Process ID of process to be connected to
2. (Optional) Initial allocation
This is the basic establish connection command. It serves a dual purpose;
to request establishing a connection, and to confirm establishing a connection.
The initial allocation defaults to zero (ie, no MSG's may be sent until an ALL
is given).
CODE 002 CLS CLOSE PROCESS CONNECTION DCP → process message
This is the basic terminate connection command. It may either terminate an
existing connection or abort a request for one.
CODE 003 ALL ALLOCATE DCP → DCP message
2. Bytes of allocation
This is the data allocation command. If this feature is used, the receiver
may send only up to the specified number of data bytes in MSG packets before it
must wait for a further allocation. Allocation only applies to data in MSG
packets; a host must be ready to accept other packets at any time. Allocations
are added to the current allocation remaining.
CODE 004 WIN SET WINDOW SIZE DCP ↔ DCP message
8. window size
This command sets the window size to other than 3 packets. This value
must be 1≤window size≤126.
CODE 005 MSG MESSAGE process ↔ process message
MSGSIZ Message passed to tertiary process
This is the basic data transmission command. The contents of the data part
are passed to the tertiary process. Data may be continuously sent until the
allocation runs out, after which no further MSG's may happen until another ALL
is given. Since packets as transmitted over DIALnet are sent in 8.-bit bytes it
is the responsibility of the tertiary protocol to do the necessary byte packing
data with a byte size of other than 8. bits.
OP CODES (continued)
CODE 006 ERR ERROR DCP ↔ DCP message
1. Error condition code:
000 Allocation has reached zero
001 Sent RPC when connection exists
002 Sent CLS when no connection exists
003 Sent ALL when no connection exists
004 Sent MSG when no connection exists
005 Sent ACK on meaningless packet
006 Packet checksum error
007 Packet violated protocol
010 Packet time-out
011 Packet received out of sequence
012 MSG exceeds allocation, wait for allocation
014 SOP expected but something else received
015 EOP expected but something else received
016 Incomplete packet (SOP received)
017 Incomplete packet (EOP received)
020 Illegal op code
021 Illegal window size
1. Packet sequence number of packet you are unhappy with
This is the command to tell the foreign host that it is losing with a
packet that it sent. The foreign host should examine the code and determine
what it is doing wrong. Code 000 does not indicate an error and means that
transmission is now frozen due to allocation reaching zero (ie, the sender is
waiting for a new allocation). Most of these codes indicate either a
transmission error or violation of network protocol.
CODE 007 ACK ACKNOWLEDGE, READY DCP ↔ DCP message
1. Packet sequence number of packet you are acknowledging.
2. (Optional) New allocation.
This command informs the foreign host that the packet with the specified
packet sequence number has be received successfully. It is also a request for
more packets to be sent; specifically it is a request for the packet with the
specified sequence number+1. If the optional allocation is specified, the
allocation is added to the current remaining allocation (unless this is a
repeated ACK, in which case it is ignored). ACK always has packet number 000.
Of course, in a repeated ACK the allocation must be the same!
CODE 010 RST RESET DCP ↔ DCP message
Close all connections, abort all processes. This command may be sent by a
host which has just been restarted following a service interruption. It
instructs the other host to forget all packets, connections, etc. RST is also
used in initially setting up a connection. RST always has packet number 000.
Once an RST is sent, no other packets (other than another RST) should be sent
until the acknowledgement comes in, and any received packet should be ignored.
EXAMPLES OF DIALNET INTERACTIONS
Please note that these examples are not meant to show the "only" way by
which these conditions can occur; rather it shows very simplified and perhaps
ideal interactions. Its main intent is to make some of the preceeding
paragraphs simpler and demonstrate how simple the DIALnet protocol actually is.
Acknowledgements are only shown for MSG packets, however all packets except
for ACK packets should be acknowledged. ACK packets are "acknowledged" by
sending more packets.
ESTABLISHING A CONNECTION REFUSING A CONNECTION
User Server User Server
RPC RPC
RPC CLS
BREAKING CONNECTION (BY USER) BREAKING CONNECTION (BY SERVER)
User Server User Server
CLS CLS
CLS CLS
NORMAL DATA TRANSMISSION NORMAL DATA TRANSMISSION
User Server User Server
MSG MSG
ACK ACK
DATA TRANSMISSION ERROR TIME OUT CONDITION (default window)
User Server User Server
MSG MSG 1
ERR MSG 2
MSG MSG 3
ACK MSG 1
ACK 1
GLOSSARY
The following terms are used in this document and are defined here to
remove ambiguity:
ACKNOWLEDGEMENT -- a verification packet stating that the specified packet was
sent properly.
ALLOCATION -- a 16.-bit quantity which specifies the number of bytes that may be
sent in MSG packets before a new allocation. This is to provide for
hosts with limited buffering. Allocation applies only to the data part
of MSG packets and not to any other type of packet.
BYTE -- an 8.-bit quantity. While DIALnet transmissions are to be considered as
a bit stream, this concept is convenient to use for many reasons.
BYTE SIZE -- this refers to the byte size of data as seen by the host computer.
All DIALnet transmissions should be considered bit stream transmissions
sent in units of 8.-bit bytes. All the DIALnet protocols except for the
FTP protocol use 8.-bit bytes.
CHECKSUM -- a 16.-bit quantity containing a CRC checksum of the packet.
CONNECTION -- a logical connection between two processes. Connections are
bidirectional.
DATA -- an arbitrary amount of data which is either used as arguments to the DCP
or as data to be passed to the processes utilizing DIALnet.
DATA COUNT -- a 8.-bit quantity indicating how many bytes are in the data field
of the packet. This quantity may be 000, in which case there is no data
field.
DIALNET -- a communications protocol for data transmission over standard phone
lines. This term also refers informally to the set of hosts which
implement DIALnet.
DIALNET CONTROL PROGRAM -- the process on each host responsible for the
host-host communications on that host. All the other processes on that
host send and receive their traffic through the DCP.
EOP -- an 8.-bit quantity indicating end of packet. The value of the EOP code
is 226 and it is a violation of protocol for a packet to end with
anything other than this code. Also, a packet can not be considered to
have been completely received until this code has been received. An EOP
that occurs at any other point must be quoted with an SOP.
HOST -- a system with DIALnet-compatible modems and DIALnet-support software
which knows the telephone number of at least one other host.
OP CODE -- a DIALnet host-host protocol operation code.
PACKET -- a logical unit of data transmitted over a DIALnet link. The packet is
the elementary unit of DIALnet transmissions. A packet is basically
data with a header and trailer.
GLOSSARY (continued)
PACKET ID -- an 8.-bit quantity which uniquely identifies a packet at a given
point in time. This is used to identify packets if necessary in error
recovery. Packet ID's may be recycled after both hosts have agreed that
the packet associated with this packet ID has been correctly sent and
received. Packet numbers start with 000 when a phone connection is
made, are incremented with each new packet, and wrap around to 000.
PROCESS -- an entity utilizing DIALnet. DIALnet traffic consists of
communications between processes.
PROCESS ID -- an ASCII string (currently 8. 8.-bit bytes) which uniquely
identifies the process.
SERVER -- the initially passive process in a connection. Note that a server is
not necessarily the receiver of the phone call, although this is
normally the case.
SOP -- an 8.-bit quantity indicating start of packet, included for redundancy.
The value of the SOP code is 227 and it is a violation of protocol for a
packet to begin with anything other than this code. Hence, unless a
packet is in the process of being transmitted, no other code other than
SOP should be transmitted or received. An SOP which occurs at any other
point must be quoted with an SOP.
TIMEOUT -- A wait time for a specified action. If the desired action does not
occur within a specified time, a "timeout" action is taken.
USER -- the initially active process in a connection. Note that a user is not
necessarily the initiator of the phone call, although this is normally
the case.
REFERENCES
The following documents describe communications protocols used in several
networks and are listed here for reference:
ARPAnet: (The first packet-switched network)
[1] ARPAnet Protocol Handbook. Feinler and Postel (editors).
Also, these updates:
[a] RFC 726 Remote Controlled Transmission & Echoing
TELNET Option. Postel and Crocker.
[b] RFC 727 TELNET Logout Option. Crispin.
[c] RFC 732 TELNET Data Entry Terminal Option. Day.
[d] RFC 733 Standard for the Format of ARPA Network Text
Messages. Pogran, Vittal, Crocker, and Henderson.
[e] RFC 734 SUPDUP Protocol. Crispin.
[f] RFC 735 TELNET Byte Macro Option. Crocker and
Gumpertz.
[g] RFC 736 TELNET SUPDUP Option. Crispin.
[h] RFC 737 FTP Extension: XSEN. Harrenstien.
[i] RFC 738 Time Server. Harrenstien.
[j] RFC 739 Assigned Numbers. Postel
[k] RFC 740 NETRJS Protocol. Braden.
[l] RFC 741 Specifications for the Network Voice Protocol.
Cohen.
[2] Specifications for the Interconnection of a Host and an IMP,
BBN Report #1822.
Also, this update:
[a] RFC 716 Interim Revision to Appendix F of BBN Report
1822. Walden and Levin.
CHAOSnet: (MIT Artificial Intelligence Laboratory local network)
[1] CHAOS ORDER. Moon.
DECnet: (Digital Equipment Corporation's communications protocols)
[1] Specification for: DDCMP (Digital Data Communications Message
Protocol). DEC.
[2] Specification for: NSP (Network Services Protocol). DEC.
[3] Specification for: DAP (Data Access Protocol). DEC.
LCSnet: (MIT Laboratory for Computer Science local network)
[1] Local Network Notes. Pogran, et al.
PCnet: (A dial-type network oriented for hobbyist and personal computers)
[1] PCnet Communication Protocols. Crane, et al.
ACKNOWLEDGEMENTS
Les Earnest (SAIL), Mike Farmwald (SAIL), John McCarthy (SAIL), Dave Moon
(MIT), and Richard Stallman (MIT) provided invaluable encouragement and
assistance in designing (and debugging) this protocol and in proofreading this
document.
I take sole responsibility for whatever is inaccurate or unclear.